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1.  Introduction 


The  Netted  Full  Spectrum  Sensor  (NFSS)  architecture  relies  on  a  full  suite  of 
state-of-the-art  ground  based  and  air  delivered  multi-intelligence  sensors.  To  ensure  that 
operational  sensor  taskings  and  missions  are  coordinated,  and  not  mutually  interfering  or 
redundant,  will  require  a  management  system  as  part  of  the  NFSS. 

The  NFSS  Operations  Management  System  (OMS)  will  allow  engineering 
decision-makers  to  perform  tradeoffs  in  sensor  requirements  and  design  parameters,  as 
well  as  support  staff  officer  decisions  in  real-time  mission  planning  and  execution.  Users 
will  be  able  to  view  unfolding  scenarios  in  faster-than-real-time  simulations  of  mission 
outcomes  for  predictive  assessments  of  alternative  sensor  and  platform  selection  as  well 
as  multi-sensor  tasking  using  what-if  scenarios.  Staff  officers  should  be  able  to  assess 
weaknesses  in  mission  plans,  predict  possible  failures,  and  recommend  changes  to  sensor 
taskings  in  real  time. 

Once  operations  are  underway,  one  must  be  able  to  monitor  actual  operations  in 
real  time  and  compare  them  to  the  simulated  scenario  to  determine  the  differences.  To 
accomplish  this  requires  that  a  user  interact  with  a  simulation  running  in  real  time,  taking 
inputs  from  actual  observation  data.  One  can  then  assess  the  effects  of  competing  tasking 
opportunities,  e.g.,  whether  to  prosecute  a  high  priority  target  in  lieu  of  an  originally 
planned  target.  This  will  allow  a  user  to  take  advantage  of  new/unforeseen  targets  of 
opportunity,  or  possibly  abort  a  mission  that  is  going  badly,  freeing  sensor  assets  for 
reuse  elsewhere. 

Under  Phase  I,  Prediction  Systems,  Inc.  (PSI)  developed  the  architecture  design 
for  the  NFSS-OMS.  This  architecture  identifies  the  modules  that  define  the  capabilities 
of  the  NFSS-OMS  and  satisfy  the  requirement  for  coordinating  disparate  MASINT 
sensor  activity  as  well  as  provide  a  Common  Operating  Picture  of  the  battlefield  with  the 
information  derived  from  the  sensor  systems.  The  NFSS-OMS  is  also  designed  to 
support  mission  planning  for  both  pre  and  post  deployment  to  optimize  sensor 
emplacement,  tasking,  and  information  gathered. 

In  addition  to  the  specific  efforts  to  design  the  architecture  and  demonstrate  the 
critical  pieces  in  operation,  PSI  has  shown  how  it’s  Computer-Aided  Design  (CAD) 
technology  provides  for  rapid  development  and  support  of  complex  real  time  control 
systems.  Using  the  General  Simulation  System  (GSS),  and  Run-Time  Graphics  (RTG) 
system,  existing  models  were  combined  with  new  models  to  produce  a  simulation  that 
demonstrates  how  the  NFSS-OMS  would  work. 
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2.  Objectives 

The  specific  Phase  I  Technical  Objective  was  to  produce  an  overall  system  design 
and  concept  of  operations  for  achieving  dynamic  situation  assessment  and  prediction. 

The  following  list  are  the  facilities  from  the  Phase  I  proposal  that  were  investigated  along 
with  a  brief  status  summary: 


•  Provide  easy-to-use  graphical  user  interfaces  at  workstations  or  on  laptops  -  for 
both  Windows  2000/NT  and  Unix/Linux.  -  The  RTG  system  used  to  develop  the 
NFSS  graphics  interface  provides  all  the  functionality  required  by  NFSS.  The 
environment  is  supported  on  both  workstations  and  laptops  as  well  as  Windows 
and  Unix  platforms. 

•  Provide  large  screen  display  support.  The  Data  Wall  at  AFRL,  Rome,  NY  is  an 
example  of  this  type  of  facility,  and  one  that  PSI  can  interface  to.  -  Initial 
technical  discussions  and  demonstrations  of  the  AFRL  Data  Wall  were  held  at 
Rome,  NY. 

•  Provide  for  3-D  visualization.  Various  facilities  (e.g.,  ERDAS,  Open-Map, 

JMAP,  and  facilities  being  developed  by  ARL)  can  be  used  by  PSI  to  provide  this 
capability.  -  Initial  analysis  of  the  facilities  needed  by  NFSS  do  not  require  3-D. 
However,  PSI  tools  provide  the  ability  to  view  the  battlespace  in  3-D. 

•  Request  and  receive  real-time  inputs  from  other  tools  or  data  sources  for  creation 
or  modification  of  databases,  use  as  scenario  or  equipment/model  parameters, 
determine  measures  of  effectiveness,  sensor  position  or  flight  path  optimization 
criteria,  etc.  -  The  sensor  interfaces  were  tested  using  simulated  systems.  The 
NFSS  prototype  established  connections  with  these  simulated  systems  as  if  they 
were  real. 

•  Maintain  local  databases  to  support  the  local  planning  functions.  Monitor 
requests  from  other  tools  for  data  -  for  security  and  other  purposes.  -  The  NFSS- 
OMS  prototype  demonstrated  the  use  of  several  databases  that  were  maintained 
including  raw  sensor  data  and  fused  sensor  data. 

•  Create  many  detailed  mission  scenarios  quickly  and  interactively  while 
simulations  are  running.  This  involves  the  use  of  hierarchies  of  entities  and  their 
corresponding  iconic  representation  visually.  It  also  requires  the  ability  to  quickly 
create  complex  paths  of  movement,  e.g.,  flight  paths,  with  multiple  waypoints, 
velocities,  altitudes,  etc.  -  Dynamic  deployment  of  new  sensors,  flight  paths,  and 
UAV  payloads  was  demonstrated  as  part  of  the  NFSS-OMS  demonstration. 

•  Recognize  prescribed  measure  thresholds  and  set  off  corresponding  alarms,  e.g., 
when  a  hostile  element  is  within  range  of  detection  by  friendly  sensors.  Alarms 
can  be  sent  or  received  from  other  tools  in  the  network.  -  This  capability  is  part  of 
the  WARNING  process  and  is  described  within  the  NFSS-OMS  design. 
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•  Determine  optimal  taskings  and  mission  outcomes  based  upon  optimization  runs. 
-  This  capability  is  part  of  the  OPTIMIZATION  facility  and  is  described  within 
the  NFSS-OMS  design. 

•  Evaluate  results  of  simulated  missions,  obtaining  data  collection  and  effectiveness 
measures  (MOEs).  Determine  probabilities  and  accuracies  of  detection, 
correlation  mechanisms,  identification  mechanisms,  success  rates,  etc.  -  These 
issues  are  addressed  throughout  the  NFSS-OMS  design  document.  Particular 
focus  on  this  issue  is  included  in  the  description  for  the  sensor  fusion  facility. 

•  Recognize  requests  and  automatically  send  real-time  outputs  to  other  tools  or  data 
sinks,  e.g.,  the  ACE-ASAS,  ACT-CGS,  ACS-GPF  and  JSTARS.  -  The  NFSS- 
OMS  addresses  this  issue  in  two  areas  of  the  design.  The  first  is  the  interface  to 
other  systems  including  sensor  systems  and  other  control  and  management 
systems.  The  other  is  the  automatic  response  facility  that  is  included  as  part  of  the 
NFSS-OMS  design. 
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3.  Research  Conducted 


The  prime  objective  of  the  Phase  I  was  to  develop  an  architecture  for  the  NFSS- 
OMS.  This  NFSS-OMS  architecture  addresses  the  capabilities  to  meet  the  design 
requirements.  These  capabilities  are  described  within  the  following  subsections. 

3.1  Development  environment 

PSI  has  a  set  of  tools  that  are  being  used  to  develop  the  NFSS-OMS  that  are 
uniquely  qualified  to  providing  the  capabilities  needed  to  satisfy  the  stated  objectives. 
These  tools  are: 

•  General  Simulation  System  (GSS)  -  GSS  is  a  simulation  environment  used  to 
quickly  build  models  and  analyze  complex  systems.  The  GSS  Optimization 
capability  provides  advanced  optimization  techniques  to  solve  highly  nonlinear 
design  problems.  This  has  been  used  to  optimize  protocol  layer  parameters, 
scenario  deployments,  design  criteria,  and  select  courses  of  action  in  real  time. 
GSS  provides  several  ways  to  interface  to  external  systems  including  basic 
TCP/IP  sockets,  XML,  DIS,  and  HLA.  The  interfaces  support  real  time  10.  GSS 
simulations  have  been  successfully  used  in  hardware-in-the-loop  experiments  and 
real-time  planning  tools. 

•  Virtual  Software  Environment  (VSE)  -  VSE  is  software  development 
environment  using  a  graphical  front  end  to  architect  and  implement  software 
systems.  VSE  is  virtually  identical  to  GSS  without  the  simulation  clock  and  most 
GSS  models  can  be  interchanged  with  VSE  modules.  This  allows  code  developed 
within  the  simulation  environment  to  be  ported  directly  to  the  software 
environment. 

•  Run-Time  Graphics  (RTG)  -  RTG  is  an  interactive  run-time  graphics  system 
available  to  GSS  and  VSE.  RTG  provides  a  visual  interactive  facility  to  deploy 
and  interconnect  hierarchical  entities,  change  scenarios,  and  measure  the 
performance  of  a  system  while  it  is  running.  Users  can  change  or  instrument  any 
part  of  a  model  and  present  the  action  on  a  high-  resolution  workstation  or  laptop 
through  manipulation  of  icons,  lines  and  instruments.  Users  can  pan  and  zoom 
over  multiple  background  overlays,  interacting  with  various  menus  and  dynamic 
elements. 

GSS/VSE/RTG  are  essentially  platform  independent.  Products  built  with  these 
tools  run  without  change  on  Windows  NT/2000/XP,  Sun  Solaris,  SGI  IRIX,  Linux,  and 
IBM  AIX. 

3.2  Mission  planning 

Mission  planning  became  quite  different  during  the  Gulf  war.  Because  of  the 
concern  for  loss  of  human  lives,  ground  combat  was  avoided  until  absolutely  necessary. 
Focus  was  on  establishing  and  maintaining  air  superiority  to  allow  continuous 
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preparation  of  the  battlefield  by  the  coalition  forces  led  by  the  U.S.  Part  of  the  everyday 
tasks  of  the  CINC’s  staff  were  the  analysis  and  prioritization  of  targets,  analysis  of 
threats,  analysis  of  weather,  selection  of  coalition  assets  to  assign  to  targets,  planning  for 
logistics  and  refueling,  and  planning  for  redirection  of  assets  as  the  situation  and 
priorities  changed. 

Although  final  decisions  on  specific  missions  were  made  at  CINC  headquarters, 
significant  inputs  came  from  many  other  planning  facilities,  including  the  national 
headquarters  of  the  different  coalition  forces.  This  type  of  planning  requires  sharing 
information  among  various  planners  in  geographically  distributed  locations.  Each  of 
these  planners  will  have  tools  to  support  their  different  functions.  But  each  may  need 
inputs  from  a  subset  of  the  others,  and  be  required  to  send  information  to  another  subset 
to  form  a  consistent  battlespace  representation,  common  operational  picture  and  predicted 
battlespace  situation. 

The  NFSS  needs  to  support  both  pre-deployment  mission  planning  for  preparation 
of  the  battlefield  as  well  as  post-deployment  mission  planning.  In  both  cases,  the  NFSS 
needs  to  provide  real-time  and  on-demand  MASINT  full  spectrum  coverage  and  data 
presentation  in  an  integrated  manner  at  all  levels  of  intelligence  from  forward  troops  to 
the  remote  command  CINC  headquarters.  These  facilities  will  likely  include  large  wall 
map  displays  with  graphical  illustrations  that  indicate  the  current  situation  for  participants 
to  see  at  a  glance.  It  will  also  include  individual  and  remote  client  workstations  so  that 
participants  can  work  specific  sensor  groups  with  the  most  suitable  planing  tools. 

Pre-deployment  mission  planning  will  consist  of  optimizing  the  emplacement  of 
MASINT  sensor  resources  within  the  battlespace  to  provide  the  most  efficient  coverage 
to  generate  the  intelligence  required  for  successful  mission  execution. 

Post-deployment  mission  planning  must  provide  an  indication  of  the  capabilities 
of  the  sensors  that  are  already  deployed  and  where  new  sensors  are  needed  to  cover 
critical  areas  of  the  battlefield. 

Visualization  of  the  battefield  is  a  key  element  in  being  able  to  provide  mission 
planning.  PSI  experimented  with  the  use  of  sensor  coverage  maps  during  Phase  I.  A 
coverage  map  can  be  used  to  determine  which  areas  of  the  battlefield  are  covered  by 
different  sensors.  The  coverage  maps  can  also  be  used  to  show  results  of  more  than  one 
sensor  (of  different  types)  to  indicate  what  area  is  covered.  Figure  1  shows  a  coverage 
map  generated  using  the  prototype  NFSS-OMS  requiring  only  one  sensor  to  cover  an 
area  and  Figure  2  shows  the  same  deployment  requiring  two  sensors  to  cover  the  area. 
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Figure  1.  Sensor  Coverage  Map  Requiring  1  Sensor 


Figure  2.  Sensor  Coverage  Map  Requiring  2  Sensors 
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3.3  Sensor  Management 


To  coordinate  effective  use  of  a  fully  integrated  set  of  sensors  as  defined  in  the 
solicitation,  the  NFSS  system  requires  interaction  with  other  planned  operational 
subsystems,  e.g.,  INTEL,  COMM,  logistics,  etc.,  as  well  as  the  control  stations  of  new 
and  existing  sensor  systems.  Depending  upon  the  mission  plans  being  formed  and 
questions  being  asked  during  a  live  operation,  various  information  exchanges  will  be 
required  with  external  systems  as  well  as  internal  NFSS  sites.  To  obtain  the  latest 
information,  queries  and  responses  will  have  to  be  interchanged  with  various  staff 
positions,  or  directly  to  the  automated  systems  used  to  support  them.  This  interaction 
involves  common  databases  shared  by  these  systems,  as  well  as  their  individual 
databases.  Many  of  these  systems  will  have  to  contribute  their  latest  information  to 
ensure  the  most  accurate  representation  of  the  current  state  of  operations,  as  well  as 
provide  the  most  accurate  projections  of  the  outcomes  of  proposed  sensor  tasks.  This  is  a 
critical  part  of  the  NFSS  system  architecture,  and  it  depends  heavily  upon  different 
communications  assets. 

Clearly,  coverage  of  the  full  spectrum  of  Measurement  And  Signature  (MASINT) 
and  EW  /  SIGINT  emissions  is  a  considerable  undertaking.  This  implies  the  selection 
and  tasking  of  multiple  types  of  sensor  assets,  implying  targeting,  mission  planning, 
communications  planning,  etc.  With  sensor  types  including  RFINT,  Chem-Bio,  Seismic, 
Acoustic,  Magnetic,  Infrared,  Imaging,  and  Weather,  tasking  multiple  sets  of  sensors  in 
real  time  is  a  significant  operational  management  problem. 

PSI  has  been  developing  planning  and  tasking  tools  to  support  CINC  staff 
operations,  determining  information  sources,  designing  system  interfaces,  and  working 
with  the  developers  of  other  systems  to  ensure  seamless  and  timely  passage  of  required 
information.  This  information  is  defined  by  the  answers  and  measures  of  effectiveness 
that  INTEL  staff  officers  expect  to  obtain  from  the  system.  PSI  has  developed  the 
embedded  simulations  that  form  the  heart  of  these  netted  tools,  and  the  real-time  inputs 
for  operational  scenario  and  other  data  required  to  drive  the  simulations  that  predict 
sensor  collection  outcomes.  These  simulations  are  used  by  the  staff  officers  to  determine 
optimized  sets  of  targets,  taskings,  and  mission  plans. 

3.4  Sensor  Fusion 

The  NFSS  will  receive  reports  from  many  MASINT  sensors.  The  accuracy  and 
level  of  detail  from  each  of  the  sensor  systems  will  vary  with  the  system’s  capabilities. 
This  will  require  the  NFSS  to  include  a  database  on  the  capabilities  of  each  sensor  type. 
The  NFSS  will  need  to  receive  and  process  this  information  and  then  provide  this 
information  in  a  coherent  manner  to  the  NFSS  operator. 

To  avoid  overwhelming  the  operator  with  raw  data,  the  NFSS  will  need  to  provide 
different  levels  of  sensor  fusion.  There  are  several  levels  of  sensor  fusion  to  aid  this 
process: 
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•  Raw  Data  Filtering  -  Some  sensor  systems  will  be  providing  a  raw  data  stream 
of  detection  information.  Some  of  these  streams  may  consist  of  unprocessed 
OPFOR  detections  that  may  be  continually  repeated  for  each  OPFOR  being 
tracked.  It  is  also  possible  that  the  sensor  system  may  not  be  able  to  perform 
Specific  Emitter  Identification  (SEI)  thus  being  unable  to  correlate  individual 
reports  belonging  to  a  single  identity.  Given  the  low-resolution  of  some  of  these 
sensors,  it  may  appear  that  several  entities  exist  where  there  may  be  only  one.  A 
raw  data  filter  can  be  used  to  aggregate  spot  reports  using  a  proximity  filter.  This 
filter  would  aggregate  spot  reports  that  are  near  each  other  thus  reducing  the 
amount  of  information  that  needs  to  be  displayed  by  NFSS.  This  would  not  be 
performed  for  sensors  that  can  perform  SEI. 

•  Disparate  Sensor  Fusion  -  Since  the  NFSS  will  be  receiving  information  from 
various  sensors,  it  is  assumed  that  different  sensor  systems  will  be  reporting  some 
of  the  same  entities.  The  various  sensor  reports  need  to  be  aggregated  into  a 
single  set  of  reports  based  on  the  information  supplied  by  each  sensor  system. 

The  combined  entity  must  provide  the  information  from  each  sensor  to  the  NFSS 
operator.  As  an  example,  a  seismic  sensor  may  indicate  the  weight  of  a  vehicle 
while  an  RF  sensor  may  indicate  the  signal  characteristics  such  as  the  frequency, 
bandwidth,  and  waveform  type,  that  the  vehicle’s  radio  is  producing.  The  sensor 
system  capabilities  database  will  be  used  to  determine  how  the  information  should 
be  aggregated.  For  instance,  a  higher-resolution  sensor’s  position  will  be  used  in 
lieu  of  a  lower-resolution  sensor’s  position. 

•  Entity  Relationship  Correlation  -  Patterns  within  the  sensor  information 
received  may  indicate  relationships  between  detected  entities.  Such  patterns  may 
be  seen  by  correlating  different  RF  transmissions  or  movement  events  following 
RF  transmissions.  These  relationships  can  then  be  made  available  to  the  NFSS 
operator  as  graphical  connections  between  the  OPFOR  icons  on  the  display 
screen. 

•  Organization  Hierarchy  Determination  -  The  pattern  of  entity  relationships  can 
be  determined  based  on  the  evolving  entity  relationships  along  with  other  spot 
report  information.  Different  RF  frequencies  used  at  a  single  site  could  be  used  to 
determine  Command  Post  entities  as  well  as  how  often  they  transmit.  The 
relationships  can  then  be  used  to  develop  the  organizational  structure  of  the 
OPFOR  deployment.  The  NFSS  will  need  to  include  a  database  of  OPFOR 
capabilities  to  determine  organizational  elements  from  some  of  this  information 
(e.g.,  radio  types  and  the  frequencies  used  by  various  command  posts). 

3.5  Display  Management 

Given  that  the  simulation  is  built  to  support  the  mission  scenarios  to  be  analyzed, 
a  graphical  user  interface  must  exist  that  allows  the  user  to  create  and  modify  complex 
scenarios  by  manipulating  icons,  lines,  instruments  and  other  facilities  built  into  the 
simulation.  This  includes  deploying  platforms  and  equipment,  including  targets,  sensors, 
radios,  satellites,  jammers,  etc.  It  also  provides  for  creation  of  paths  for  movement  of 
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satellites,  aircraft,  UAVs,  helicopters,  ground  vehicles,  and  other  platforms,  and  the 
selection  of  specific  platforms  to  attach  to  those  movement  paths.  This  simulation  can 
account  for  the  dynamics  of  a  fast  moving  scenario  and  measures  of  mission 
effectiveness  as  well  as  specific  equipment  performance.  The  nature  of  PSI’s  simulation 
facilities  allows  this  to  be  done  while  the  simulation  is  running.  Furthermore,  this  allows 
real  time  comparison  of  alternative  sensors,  taskings,  designs,  etc. 

Models  exist  for  allowing  the  user  to  click  down  many  way  points  for  a  complex 
movement  path,  attach  one  or  more  specified  platforms  to  that  path,  and  have  them  move 
individually  or  together  to  follow  the  path  prescribed  by  the  mission.  The  user  can  assign 
equipment  and  C2  decision  elements  to  each  platform  so  that  as  they  move,  they  can  send 
and  receive  electronic  signals  and  messages,  and  react  as  they  would  using  smart  models 
guiding  the  platforms.  This  allows  alternatives  to  be  created,  tested,  and  compared  on- 
the-fly. 


While  interfacing  with  a  running  simulation,  the  user  can  interactively  describe 
ranges  for  unknown  parameters,  e.g.,  waypoints  along  movement  paths,  to  optimize 
specified  measures  of  effectiveness.  The  optimization  facilities  built  into  GSS  will  then 
run  as  many  simulations  as  desired  to  first  determine  if  a  feasible  solution  exists,  and  then 
to  come  up  with  an  optimal  set  of  parameters. 

After  the  sensor  information  has  been  fused  to  provide  a  concise  presentation  to 
the  NFSS-OMS  operator,  the  ability  to  drill  down  through  a  composite  entity  to  view  the 
raw  sensor  data  should  be  provided.  This  can  easily  be  accomplished  using  the 
hierarchical  graphics  capabilities  inherent  within  the  GSS,  VSE,  and  RTG  and  tools. 

The  technology  embedded  in  these  tools,  for  determining  optimized  parameters 
by  running  a  large  number  of  simulations  automatically,  has  evolved  to  a  point  where 
users  of  the  existing  tools  are  now  thinking  well  beyond  their  future  concepts  of  one  or 
two  years  ago.  The  technology  for  sharing  models  of  hierarchies  of  entities,  and  the  use 
of  hierarchical  icons  to  represent  these  entities  has  also  evolved  to  allow  extremely  rapid 
development  of  simulations  of  huge  complex  scenarios.  These  simulations  can  be 
instrumented  in  many  ways,  and  the  resulting  measures  of  performance  and  effectiveness 
can  be  used  to  produce  the  design  envelopes  for  the  sensors,  sensor  mixes,  and 
approaches  to  multi-sensor  tasking. 

3.6  Information  Sharing 

The  NFSS  will  not  be  the  only  system  that  needs  to  collect  and  track  sensor 
information  on  the  battlefield.  The  NFSS-OMS  will  need  to  include  interfaces  to  support 
data  sharing  with  other  management  and  decision  aid  systems  and  databases.  This 
interface  must  support  automatic  sharing  of  data  in  both  directions.  Information  received 
from  other  management  systems  must  be  incorporated  with  the  received  sensor  data  and 
provided  on  the  operator’s  screen. 

Data  can  be  extracted  from  local  database  management  systems  that  typically 
reside  on  servers.  Examples  of  database  systems  are  ORACLE,  SYBASE,  ACCESS,  etc. 
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Depending  upon  security  levels,  one  may  need  to  go  through  a  procedure  to  scrub  files 
that  will  be  mixed  with  lower  levels  of  classification.  In  these  cases,  files  may  be 
formatted  during  the  extraction  process.  Canned  request  forms  or  panels  can  be  stored  to 
make  it  easy  for  users  to  do  this. 

Situational  information  may  be  distributed  across  multiple  distributed  local 
databases.  Each  tool  could  contain  its  own  local  database,  as  opposed  to  storing  the  data 
for  all  tools  in  a  centralized  database.  (We  do  not  preclude  a  centralized  repository.) 
Updates  to  this  local  database  can  be  coming  in  from  other  tools  and  databases  via  the 
real  time  inputs  channels.  The  NFSS  OMS  control  system  will  feed  them  through  the 
database  update  and  extraction  module  for  input  to  the  database.  Elements  of  this 
database  will  be  available  to  the  simulation,  optimization  and  control  systems  of  the 
NFSS  OMS.  Subsets  of  this  database  will  be  stored  in  formats  for  high  speed  processing 
in  support  simulations.  These  subsets  will  be  stored  in  the  immediate  databases  required 
for  specific  scenario  runs. 
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4.  NFSS-OMS  Architecture 


The  NFSS-OMS  prototype  was  built  using  GSS.  Figure  3  shows  the  architecture 
for  the  NFSS-OMS  prototype  that  was  developed  during  Phase  I.  This  architecture 
consists  of  many  of  the  main  models  that  will  be  refined  during  Phase  n.  The  following 
sections  describe  the  top  level  models  of  the  NFSS-OMS  as  they  are  currently 
implemented  within  the  prototype  developed  during  Phase  I. 


NFSS_0f1S 
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Figure  3.  NFSS-OMS  Model  Architecture 
4.1  NFSS.CONTROL  Model 

The  NFSS_CONTROL  Model  is  the  main  model  within  the  NFSS-OMS  that 
controls  the  actions  and  interfaces  to  the  system.  The  activities  controlled  by  this  model 
are  discussed  in  the  following  subsections. 
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4.1.1  Interactive  Graphics  Events 

The  graphics  events  generated  by  RTG  from  the  user  interactive  interface  are 
fielded  within  the  NFSS_CONTROL  Model.  The  following  graphics  events  are  currently 
supported: 

•  Function  Buttons  -  RTG  supports  the  use  of  8  function  buttons  that  can  be 
assigned  by  the  system  developer  on  the  button  interface.  These  buttons  change 
dynamically  to  support  the  activity  that  is  currently  being  performed.  The  main 
set  of  buttons  are  currently  used  to  invoke  the  Sensor  Coverage  Map  and  Path 
Manager  capabilities.  The  Path  Manager  capability  temporarily  redefines  the 
buttons  to  support  defining  and  modifying  paths  for  movement. 

•  Icon  Events  -  The  NFSS-OMS  supports  the  deployment  of  different  types  of 
sensors  to  determine  what  parts  of  the  area  of  interest  have  coverage.  These 
sensors  can  be  moved  and  their  parameters  updated. 

4.1.2  Sensor  System  Interface  Events 

The  NFSS-OMS  supports  connections  from  external  sensor  systems  to  receive 
sensor  deployment  and  reporting  information.  During  initialization,  the  NFSS-OMS 
starts  a  separate  task  to  handle  external  sensor  system  connections  made  using  TCP/IP. 
The  NFSS-CONTROL  model  receives  the  sensor  information  from  the  connection  server 
via  a  queue.  The  queue  has  been  designed  to  periodically  suspend  graphic  updates  for 
short  periods  of  time  as  needed  to  avoid  overflow  conditions  when  large  amounts  of  data 
are  streaming  in. 

4.2  WARNING_PROCESSOR  Model 

The  WARNING_PROCESSOR  Model  attempts  to  associate  an  entity  type  based 
on  the  emitter  characteristics  detected.  During  initialization,  the  model  reads  2  input 
files.  The  first  file  is  an  enumeration  of  the  different  types  of  waveforms  that  can  be 
reported.  The  second  file  associates  a  given  set  of  signal  characteristics  with  a  type  of 
platform  and  an  alert  level. 

For  each  spot  report  received,  the  WARNING_PROCESSOR  model  determines 
the  associated  platform  type  and  warning  level.  If  the  warning  level  exceeds  a  specified 
threshold,  the  spot  report  is  highlighted  and  a  panel  is  displayed  on  the  NFSS-OMS  with 
the  alert  information.  Figure  4  shows  a  sample  alert  panel  from  the  prototype. 
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WARNING! 

EWS  HAS  DETECTED  AN 

ALERT  LEVEL: 


1 005  [ 

POSSIBLE: 


Figure  4.  Sample  Warning  Processor  Alert  Panel 
4.3  FUSION  Model 

The  FUSION  Model  supports  a  simple  2  level  fusion  hierarchy  based  on  spot 
report  proximity.  Spot  reports  with  the  same  waveform  information  are  fused  if  the 
locations  reported  are  within  a  specified  distance  from  each  other. 

By  default,  the  NFSS-OMS  displays  fused  spot  reports.  The  user  may,  however, 
uncover  the  fused  spot  report  to  view  the  individual  spot  reports  that  were  combined  to 
form  the  fused  report.  Each  spot  report  is  color  coded  to  indicate  the  waveform 
characteristics  reported.  A  legend  can  be  displayed  showing  the  relationship  between  the 
spot  report  colors  and  the  waveform  types.  Both  fused  and  unfused  reports  can  be 
clicked  on  to  view  an  information  panel  with  the  spot  reports  information.  A  sample 
panel  is  shown  in  Figure  5. 
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Figure  5.  Sample  Spot  Report  Information  Panel 
4.4  MOVEMENT  Model 

The  movement  manager  allows  for  the  creation,  modification,  and  management  of 
platform  movement  paths.  The  path  manager  allows  great  flexibility  in  creating,  re¬ 
using,  modifying,  and  managing  flight  paths.  As  shown  in  Figure  6,  an  aircraft  flight 
path  may  be  represented  in  three  dimensions  by  up  to  100  consecutive  points. 
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P1(x,y,z,vel) 


Figure  6.  Flight  Path  Geometry 

Points  may  be  laid  down,  moved,  and  deleted  interactively.  The  path  profile 
model  will  compute  the  kinematics  parameters  required  to  move  an  aircraft  through  each 
segment  at  constant  velocity.  Any  turning  point  on  the  path  may  be  “smoothed”  by  an 
arc  circle-segment  as  shown  at  the  bottom  of  Figure  6.  The  arc  is  created  using  a  y-G 
turn  through  the  apex  of  the  two  connected  flight  path  segments  while  ensuring  a 
maximum  allowed  acceleration  or  G-force  is  not  exceeded. 

Paths  may  be  designated  as  a  loop  (go  back  to  initial  point  after  last  point) 
allowing  racetrack  patterns.  Provisions  exist  to  designate  points  between  segments  as 
delay  points  enabling  aircraft  to  hover  in  stationary  positions  or  to  touch  down  and  refuel. 
By  constructing  a  vertical  flight  path  segment,  the  aircraft  emulates  pop-up  tactics.  By 
further  defining  the  topmost  point  as  a  delay  point,  the  aircraft  may  perform  surveillance 
or  stand-off  engagement  functions. 
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Moving  platforms  are  affiliated  with  path  profiles  to  determine  their  motion 
dynamics.  Any  number  of  allowed  platforms  may  be  affiliated  with  any  one  path. 
Platforms  may  be  inserted  into  active  simulations  and  affiliated  with  paths  interactively. 
When  a  platform  is  defined  in  a  simulation  it  may  be  “loaded”  with  any  of  the  available 
sensors. 

4.5  SIMULATED_SENSORS  Model 

The  NFSS-OMS  supports  the  deployment  of  sensors  to  support  mission  planning. 
The  sensors  can  be  deployed,  moved,  and  their  parameters  modified.  The  current 
prototype  supports  both  SIGINT  and  LOS  sensor  types.  The  SIMULATED_SENSORS 
Model  consists  of  3  submodels  described  in  the  following  sections.  Information  panels 
can  be  used  to  show  the  parameter  settings  of  the  sensors. 

4.5.1  SENSOR  Model 

The  SENSOR  model  simulates  a  SIGINT  sensor.  The  model  attempts  to  detect 
OPFOR  entities  as  they  emit  signals.  The  ENVIRONMENT  model  is  used  to  determine 
the  signal  loss  between  the  emitters  and  sensors.  Signal  to  Noise  Ratios  (SNR)  that 
exceed  the  minimum  detection  threshold  will  cause  a  sensor  to  generate  a  spot  report. 

4.5.2  SENSOR.LOS  Model 

The  SENSOR_LOS  model  is  similar  to  the  SENSOR  model  except  that  it  detects 
OPFOR  units  that  it  has  Line-Of-Sight  with  without  the  requirement  of  the  OPFOR 
having  to  emit  a  signal.  The  ENVIRONMENT  model  is  used  to  determine  the  whether  a 
sensor  has  LOS  with  an  OPFOR  unit.  Each  unit  that  the  SENSOR_LOS  model  detects 
will  generate  a  spot  report. 

4.6  ENVIRONMENT  Model 

The  ENVIRONMENT  model  uses  Fast  Propagation  Prediction  System  (FPPS)  to 
determine  the  propagation  loss  between  emitters  and  SIGINT  sensors.  It  is  also  used  to 
determine  whether  LOS  exists  between  OPFOR  units  and  LOS  sensors. 

4.7  UTILITIES 

The  UTILITIES  model  contains  the  utilities  that  are  used  by  the  various  models 
within  the  NFSS-OMS  system.  This  model  consists  of  the  following  4  utilities: 

•  FPPS_ACCESS  -  The  FPPS_ACCESS  provide  the  interface  to  the  FPPS  library 
supporting  foliage  and  propagation  loss  computations. 

•  DDHHMMSS_ACESS  -  The  DDHHMMS S_ACCESS  utility  provides  access  to 
the  library  module  that  converts  time  between  several  formats. 
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•  POINT_TO_LINE_DISTANCE  -  The  P01NT_T0_LINE_DIST ANC E  utility 
provides  access  to  the  library  model  that  computes  the  distance  from  a  point  to  a 
line. 

•  ATANXY_ACCESS  -  The  ATANXY_ACCESS  utility  provides  access  to  the 
library  module  that  determines  the  positive  or  negative  angle  associated  with  a 
point  relative  to  an  origin. 
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5.  Demonstrations 


As  part  of  the  Phase  I  effort,  PSI  provided  a  demonstration  of  an  NFSS-OMS 
prototype.  The  prototype  demonstrated  several  of  the  required  NFSS  capabilities: 

•  Graphical  Interface  -  The  NFSS-OMS  prototype  makes  use  of  all  the 
capabilities  of  PSI’ s  Run-Time  Graphics  (RTG)  facility.  This  includes  the 
ability  to  pan  and  zoom,  display  background  overlays,  deploy  icons,  etc.  The 
demonstration  showed  how  sensors  could  be  deployed  and  configured  from 
the  NFSS-OMS.  Figure  7  shows  a  configuration  panel  for  one  of  the  sensors. 
These  parameters  can  be  updated  and  expanded  as  the  support  for  new  sensor 
systems  are  identified  and  added.  As  a  result  of  prototyping,  additional 
requirements  have  been  identified  for  implementation  in  Phase  n.  Examples 
are  the  graphical  representation  of  spot  report  aging  and  special  identifiers  for 
new  spot  reports. 


Figure  7.  Updating  Sensor  Parameters 

•  Sensor  Fusion  -  The  sensor  fusion  currently  implemented  is  the  first  order 
fusion  process  consisting  of  a  simple  proximity  filter.  This  capability  was 
demonstrated  by  showing  how  the  spot  reports  on  the  NFSS-OMS  screen 
were  a  reduced  set  of  the  deployment  on  the  OPFOR  screen.  Phase  II  will 
provide  additional  levels  of  sensor  fusion  and  operator  selection  of  fusion 
parameters. 
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•  Sensor  Interface  -  When  the  NFSS  is  turned  on,  it  automatically  starts  a 
separate  process  to  listen  for  connections  from  sensor  systems.  The  sensor 
systems  were  simulated  in  the  demo  by  creating  actual  TCP/IP  connections 
with  the  NFSS-OMS.  Once  a  connection  is  establish,  this  process  maintains 
the  stream  of  data  received  from  the  sensor  system  and  queues  the  information 
for  processing  by  the  NFSS-OMS.  The  sensor  interface  process  uses  the  GSS 
capability  for  sharing  data  between  processes. 

•  Coverage  Maps  -  To  support  mission  planning  and  effectiveness,  the 
capability  to  show  sensor  coverage  was  demonstrated  with  the  NFSS-OMS 
prototype.  Coverage  maps  can  be  generated  with  any  combination  of  sensor 
types.  The  number  of  sensors  that  are  required  to  cover  an  area  can  also  be 
specified.  Figure  1  and  Figure  2  show  examples  of  coverage  maps  with 
different  sensor  requirement  settings.  Phase  n  will  extend  this  capability  to 
support  additional  parameter  settings  for  each  sensor  type  and  analyze  optimal 
alternatives  for  representing  coverage  visually. 

•  Sensor  Deployment  -  In  addition  to  receiving  sensor  deployment  information 
from  the  sensor  interface,  the  NFSS-OMS  supports  the  interactive  deployment 
of  sensors  directly  on  the  scene.  Sensor  deployments  and  parameter  settings 
are  stored  in  a  time  ordered  log  file.  These  sensor  locations  and  parameters 
can  also  be  read  in  from  a  time  ordered  file  of  the  same  format  as  the  log  file. 
This  provides  the  ability  to  replay  scenarios  and  perform  “what-if  ’  type 
analyses. 

•  Sensor  Report  Processing  -  As  sensor  reports  are  received,  they  are 
processed  by  the  fusion  facility  and  displayed  on  the  NFSS-OMS.  Displayed 
OPFOR  entities  can  be  selected  and  an  information  panel  brought  up  with  the 
parametric  information  on  the  entity  displayed.  Phase  II  will  support 
hierarchical  spot  report  resolution  where  icons  representing  fused  data  can  be 
uncovered  to  reveal  the  information  that  contributed  to  the  fused  data. 

•  Airborne  Platform  Support  -  The  NFSS-OMS  provides  the  ability  to  define 
airborne  platform  flight  paths  for  deploying  sensor  packages.  Once  the 
waypoints  of  the  flight  path  are  defined,  one  or  more  airborne  platforms  can 
be  assigned  to  that  flight  path.  Each  platform  can  then  have  one  or  more 
sensor  packages  assigned  to  it  including  C2  elements  and  communications 
equipment.  Figure  8  shows  a  defined  flight  path  with  an  airborne  platform. 
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Figure  8.  Flight  Path  Specification 

To  demonstrate  the  NFSS,  additional  simulations  were  developed  to  support 
testing  the  NFSS-OMS  prototype.  The  simulation  environment  used  for  the 
demonstration  is  shown  in  Figure  9.  The  following  simulations  were  included  within  the 
test  suite: 

•  OPFOR  Simulation  -  The  OPFOR  simulation  includes  a  full  graphical  capability 
to  deploy  and  update  OPFOR  entities.  The  simulation  provides  default  OPFOR 
capabilities  with  the  ability  to  easily  change  any  entity  parameters  through 
graphical  panels.  The  simulation  records  all  transactions  to  a  log  file  which  can 
then  be  used  to  rerun  the  OPFOR  deployment  scenario.  OPFOR  parameters 
include  the  specification  of  RF  emission  characteristics. 

•  Sensor  Simulation  -  A  generic  RF  sensor  system  was  developed  to  provide 
initial  testing  of  the  NFSS-OMS.  The  simulation  includes  a  full  graphical 
capability  to  deploy  sensors  and  specify  their  capabilities  parametrically  via 
graphical  panels.  The  simulation  tracks  all  emissions  from  the  OPFOR  simulation 
to  determine  which  sensors  can  detect  the  emitting  OPFOR  entity.  Sensor 
detections  are  then  reported  to  the  NFSS-OMS. 

The  prototype  demonstration  test  suite  used  the  inter-processor  communications 
capabilities  of  GSS: 
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•  TCP/IP  -  The  communications  channel  automatically  established  between  the 
NFSS-OMS  and  the  sensor  systems  used  standard  TCP/IP  connections  to 
represent  a  real  world  system  connection.  The  NFSS-OMS  establishes  a  server  at 
initialization  to  accept  and  maintain  connections  with  sensor  systems.  The  Sensor 
simulation  was  designed  to  be  a  client. 

•  High-Level  Architecture  (HLA)  -  GSS  has  built  in  support  for  the  HLA 
protocol.  This  protocol  is  a  simulation  interface  standard  designed  to  allow 
disparate  simulations  to  communicate  with  each  other.  The  GSS  implementation 
of  HLA  provides  the  capability  to  interface  multiple  simulations  without  having 
to  worry  about  the  communications.  For  the  prototype  demonstration,  the 
OPFOR  entity  information  is  published  on  the  network  for  any  other  simulation  to 
receive  and  process.  The  Sensor  simulation,  as  well  as  the  sensor  models  within 
the  NFSS-OMS,  subscribe  to  this  information  for  processing. 


Figure  9.  Phase  I  Demonstration  Simulation  Environment 

The  NFSS-OMS  and  the  separate  simulations  can  each  run  on  separate  computers 
over  a  network  or  on  the  same  computer.  For  the  Phase  I  demonstration,  the  NFSS-OMS 
was  run  on  a  computer  by  itself  and  the  other  simulations  were  run  on  a  second  computer. 
This  separation  was  chosen  to  highlight  the  typical  environment  where  the  NFSS-OMS 
would  be  running  by  itself  while  receiving  sensor  information  over  the  network. 

5.1  Testing  with  UACEP  Data 

As  part  of  meeting  the  WECM  STO  requirements,  I2WD  has  been  participating  in 
the  Future  Combat  System  (FCS)  virtual  simulation  experiments  held  at  the  Mounted 
Maneuver  Battle  Lab  (MMBL)  at  Ft.  Knox.  The  latest  experiment  was  for  the  Unit  of 
Action  Concept  Experimentation  Program  (UACEP).  Although  I2WD  has  laboratories 
where  WECM  prototypes  can  be  analyzed  from  a  technical  perspective,  the  MMBL 
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experiments  provide  an  environment  where  the  value  of  WECM  to  the  soldier  can  be 
analyzed  more  fully.  These  experiments  help  to  meet  the  STO’s  objective  of  evaluating 
the  visualization  techniques  used  for  WECM. 

The  UACEP  experiment  was  held  1-25  April,  2002  at  the  MMBL.  During  this 
time  12 WD  supported  the  soldier  training,  Situational  Training  Exercise  (STX),  Pilot  Test 
and  the  four  Record  Trials.  The  WECM  Model  Suite  was  used  to  model  the  WECM 
sensor  system  within  the  virtual  simulation  environment.  The  models  use  the  nascent 
High  Level  Architecture  (HLA)  standard  that  is  being  mandated  for  newly  developed 
models.  To  interface  with  legacy  distributed  virtual  simulation  environments  such  as  the 
Distributed  Interactive  Simulation  (DIS)  environment,  an  HLA/DIS  gateway  was 
developed  as  part  of  the  WECM  Model  Suite. 

The  WECM  Model  Suite  contains  a  WECM  Logger  that  is  a  simple  federate  that 
subscribes  to  all  the  HLA  interactions  within  the  federation  and  logs  their  contents  to  a 
file.  Each  data  entry  within  the  file  is  time  stamped  for  further  data  analysis. 

A  new  simulation  was  developed  to  process  the  WECM  logs  from  the  UACEP 
experiment  and  provide  a  stream  of  spot  reports  over  a  connection  to  the  NFSS-OMS. 
The  NFSS-OMS  processed  the  inbound  spot  reports  and  provided  the  first  level  of  data 
fusion.  The  fused  data  was  then  displayed  graphically  by  the  NFSS-OMS  as  shown  in 
Figure  10. 

5.2  Data  Fusion 

The  NFSS  will  receive  reports  from  many  MASINT  sensors.  The  accuracy  and 
level  of  detail  from  each  of  the  sensor  systems  will  vary  with  the  system’s  capabilities. 
This  will  require  the  NFSS  to  include  a  database  on  the  capabilities  of  each  sensor  type. 
The  NFSS  will  need  to  receive  and  process  this  information  and  then  provide  this 
information  in  a  coherent  manner  to  the  NFSS  operator. 
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Figure  10.  WECM  UACEP  Deployment  with  Sensor  Fusion 


To  avoid  overwhelming  the  operator  with  raw  data,  the  NFSS  needs  to  provide 
different  levels  of  sensor  fusion.  The  sensor  fusion  process  should  not  result  in  lost  data. 
The  fusion  process  should  result  in  a  hierarchical  database  where  higher  levels  in  the 
hierarchy  can  be  uncovered  to  view  the  information  that  was  fused  together.  As  an 
example,  the  icon  for  an  OPFOR  entity  may  be  uncovered  to  provide  several  individual 
spot  reports  from  various  disparate  sensors.  Each  of  these  spot  reports  may  then  be 
uncovered  to  view  multiple  spot  reports  from  the  same  sensor  system  that  were  filtered. 

The  NFSS-OMS  was  updated  to  demonstrate  this  capability  with  the 
implementation  of  a  2-level  sensor  fusion  hierarchy.  This  capability  was  tested  with  the 
WECM  UACEP  log  files.  The  hierarchical  fusion  capability  within  NFSS-OMS 
currently  fuses  data  on: 

•  Signal  Frequency 

•  Signal  Bandwidth 
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Waveform  Type 


•  Proximity 

By  default,  the  NFSS-OMS  graphically  displays  fused  spot  reports  on  a 
background  overlay.  The  color  of  the  icon  was  used  to  represent  the  signal 
characteristics  of  the  spot  report  to  provide  immediate  feedback  to  the  NFSS-OMS 
operator  at  a  glance.  Specific  information  can  be  viewed  within  a  panel  for  individually 
selected  spot  reports.  The  capability  to  uncover  a  fused  spot  report  was  added  to  show 
the  raw  spot  report  information  that  was  combined  to  generate  the  fused  spot  report. 
Each  of  these  raw  spot  reports  also  supports  the  ability  to  bring  up  an  information  panel. 
Figure  1 1  shows  the  result  of  uncovering  one  of  the  fused  spot  reports  in  Figure  10. 


Figure  11.  Uncovered  Fused  Spot  Report  Revealing  Raw  Spot  Report  Information 
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6.  Technical  Feasibility 

PSI  has  been  developing  planning  and  tasking  tools  to  support  CINC  staff 
operations,  determining  information  sources,  designing  system  interfaces,  and  working 
with  the  developers  of  other  systems  to  ensure  seamless  and  timely  passage  of  required 
information  for  years.  This  information  is  defined  by  the  answers  and  measures  of 
effectiveness  that  INTEL  staff  officers  expect  to  obtain  from  the  system.  PSI  has 
developed  the  embedded  simulations  that  form  the  heart  of  these  netted  tools,  and  the 
real-time  inputs  for  operational  scenario  and  other  data  required  to  drive  the  simulations 
that  predict  sensor  collection  outcomes.  These  simulations  are  used  by  staff  officers  to 
determine  optimized  sets  of  targets,  taskings,  and  mission  plans. 

PSI  has  reviewed  the  NFSS  requirements  and  feels  that  the  use  of  its  tools  to 
develop  the  NFSS  provides  an  extremely  high  probability  of  success.  Several  other 
systems  being  developed  for  the  Army  have  identified  the  value  of  interfacing  with  NFSS 
and  expresses  support  for  a  Phase  H  effort  by  PSI.  The  PSI  development  environment  is 
uniquely  suited  to  providing  the  capabilities  needed  to  design,  implement,  and  support  the 
NFSS.  In  fact,  the  prototype  developed  during  Phase  I  already  demonstrates  most  of  the 
features  that  will  be  required  in  the  final  system. 
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7. 


Phase  II  Plans 


7.1  Technical  Objectives 

To  satisfy  the  increasing  need  for  intelligence  information  on  the  battlefield,  new 
Measurement  and  Signal  Intelligence  (MASINT)  sensors  are  being  developed.  Some  of 
the  requirements  for  these  sensors  are:  remote  deployability,  remote  control,  low  power, 
low  probability  of  detection  (LPD),  low  cost,  and  high  reliability.  These  sensors  typically 
utilize  a  communication  network  to  pass  control  and  collected  data  to  a  central  control 
station.  These  stations  would  then  be  manned  by  someone  in  charge  of  maintaining  that 
set  of  sensors. 

The  concept  of  a  Netted  Full  Spectrum  Sensor  (NFSS)  Operations  Management 
System  (OMS)  was  developed  to  manage  these  disparate  sensor  systems  via  an  integrated 
interface.  The  NFSS-OMS  will  coordinate  operational  sensor  taskings  and  missions  to 
ensure  sufficient  intelligence  gathering  in  an  efficient  manner  to  optimize  use  of  limited 
resources  and  avoid  excessive  redundancy  between  disparate  sensor  systems.  Mission 
planning  needs  to  take  into  account  the  ability  to  deliver  the  required  sensors  where 
needed.  To  provide  full  coverage  of  the  MASINT  spectrum  using  an  integrated 
approach,  the  NFSS-OMS  system  must  support  a  full  suite  of  state-of-the-art  ground 
based  and  air  delivered  multi-intelligence  sensors. 

To  coordinate  the  effective  use  of  a  fully  integrated  set  of  sensors,  the  NFSS- 
OMS  system  will  require  interaction  with  other  planned  operational  subsystems,  e.g., 
INTEL,  COMM,  logistics,  etc.,  as  well  as  the  control  stations  of  new  and  existing  sensor 
systems.  Depending  upon  the  mission  plans  being  formed  and  questions  being  asked 
during  live  operations,  various  information  exchanges  will  be  required  with  external 
systems  as  well  as  internal  NFSS  sites.  To  obtain  the  latest  information,  queries  and 
responses  will  have  to  be  interchanged  with  various  staff  positions,  or  directly  to  the 
automated  systems  used  to  support  them.  This  interaction  involves  common  databases 
shared  by  these  systems,  as  well  as  their  individual  databases.  Many  of  these  systems 
will  have  to  contribute  their  latest  information  to  ensure  the  most  accurate  representation 
of  the  current  state  of  operations,  as  well  as  provide  the  most  accurate  projections  of  the 
outcomes  of  proposed  sensor  tasks.  This  is  a  critical  part  of  the  NFSS-OMS  system 
architecture,  and  it  depends  heavily  upon  different  communications  assets. 

Clearly,  coverage  of  the  full  spectrum  of  MASINT  and  EW  /  SIGINT  emissions  is 
a  considerable  undertaking.  This  implies  the  selection  and  tasking  of  multiple  types  of 
sensor  assets,  implying  targeting,  mission  planning,  communications  planning,  etc.  With 
sensor  types  including  RFINT,  Chem-Bio,  Seismic,  Acoustic,  Magnetic,  Infrared, 
Imaging,  and  Weather,  tasking  multiple  sets  of  sensors  in  real  time  is  a  significant 
operational  management  problem. 

The  Phase  II  Technical  Objectives  cover  development  of  a  set  of  operations 
sensor  management  tools  that  refine  and  extend  the  functional  objectives  derived  in  Phase 
I.  The  Phase  II  technical  objectives  are: 
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•  Develop  a  WECM  Coordination  Simulation  —  This  simulation  will  be  used  to 
design  and  optimize  the  WECM  sensor  coordination  process  and  will  be 
integrated  within  the  NFSS  set  of  tools.  The  development  of  this  simulation  will 
also  include  an  analysis  of  the  WECM  coordination  process  with 
recommendations  on  how  to  implement  the  algorithms.  These  recommendations 
will  become  part  of  the  WECM  design  transitioned  to  PM  TRCS  for 
implementation  within  the  Joint  Tactical  Radio  System  (JTRS). 

•  Develop  a  Sensor  Interface  Management  Facility  -  This  facility  will  support 
the  sensor  system  and  management  interfaces  required  by  the  NFSS.  This  facility 
will  be  used  to  provide  the  communications  necessary  to  receive  sensor  status  and 
reporting  information  as  well  as  send  sensor  control  information.  It  will  also  be 
used  to  support  communications  with  other  management  facilities  to  share  and 
coordinate  acquired  sensor  data.  This  Sensor  Interface  Management  Facility  will 
be  used  to  support  the  development  of  the  ACMS  sensor  system  currently  under 
development. 

•  Develop  a  Simulation  Interface  Facility  -  This  facility  will  provide  the  gateway 
capability  to  integrate  the  NFSS  within  multiple  virtual  simulation  environments. 
It  will  be  used  to  support  the  FCS  experiments  at  the  MMBL,  Ft.  Knox. 

•  Develop  an  NFSS-OMS  -  This  tool  will  provide  an  implementation  of  the  NFSS- 
OMS  within  a  laptop  environment.  The  NFSS-OMS  will  provide  sensor  control 
and  optimization,  both  pre  and  post  deployment,  to  support  mission  planning 
decissions.  It  will  also  integrate  the  aforementioned  simulations  and  facilities  as 
shown  in  Figure  12.  Figure  12  also  shows  current  projects  that  will  directly 
benefit  from  the  output  of  this  Phase  n. 
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Figure  12.  NFSS  Components  and  Supported  Projects 

Because  the  requirements  of  this  SBIR  project  are  directly  applicable  to  project 
work  that  PSI  is  currently  doing  with  I2WD,  our  work  plan  is  aimed  at  performing 
research  and  producing  designs  that  can  achieve  demonstrable  results  in  field 
tests/exercises  in  which  these  organizations  participate. 

The  Intelligence  and  Information  Warfare  Simulation  (IIWS)  Laboratory  supports 
research  and  development  of  enhancements  to  intelligence  and  information  warfare 
system  performance  envelopes.  The  advanced  software  environment,  current  systems 
trainers,  and  simulators  resident  in  the  laboratory  form  a  unique  capability  for  the  Army 
within  I2WD.  I2WD’s  mission  is  to  provide  the  U.S.  Army  effective  Intelligence  and 
Information  Warfare  by  providing  an  effective  Signals  Intelligence  (SIGINT),  Electronic 
Warfare,  Measurement  and  Signature  Intelligence  (MASINT),  Information  Operations 
(IO)  and  Intelligence  dissemination/fusion  material  capability  to  the  U.S.  Army  through: 

•  Superior  technology  development,  prototype  demonstrations,  and  rapid  transition 
of  state-of-the-art  techniques  into  systems. 

•  Development,  production  and  fielding  of  specified  equipment  in  support  of  Army 
and  National  Intelligence  requirements  and  Law  Enforcement  Agencies  (LEA). 

•  Engineering  and  management  support  to  Program  Executive  Officers  (PEOs)  and 
their  Program  Managers  (PMs)  in  the  development,  production  and  fielding  of 
systems. 
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•  Continuous  improvement  in  productivity  and  fielding  of  systems. 

Since  the  NFSS  project  requires  integration  of  multiple  sensor  systems,  we 
believe  the  IIWS  environment  to  be  an  ideal  proving  ground  for  the  NFSS  OMS.  The 
need  to  tie  multiple  tools  and  databases  together  is  clearly  required  at  the  CINC  and 
Ground  Operations  Center  staff  level.  This  operational  environment  places  critical 
design  constraints  on  an  NFSS-OMS.  These  constraints  imply  synchronization  with 
other  tools  and  databases  as  well  as  synchronization  of  real  and  simulated  time.  It  brings 
in  the  data  coherency  problem  familiar  to  the  parallel  processing  community.  PSI  has 
built  into  GSS  the  ability  to  transparently  and  effectively  deal  with  distributed  processing 
and  also  has  the  ability  to  interface  with  diverse  databases.  These  solutions  can  be  tested 
in  the  HWS  Laboratory. 

7.2  Applicability 

The  NFSS-OMS  being  developed  under  this  SBIR  satisfies  the  requirement  for 
coordinating  disparate  MASINT  sensor  activity  and  provides  a  Common  Operating 
Picture  of  the  battlefield  with  the  information  derived  from  the  sensor  systems.  The 
NFSS-OMS  is  also  designed  to  support  mission  planning  for  both  pre  and  post 
deployment  to  optimize  sensor  emplacement  and  information  gathered. 

Several  areas  have  already  been  identified  that  will  benefit  immediately  from  the 
development  of  the  NFSS-OMS  under  Phase  II: 

•  Warfighter  Electronic  Collection  and  Mapping  (WECM)  -  The  Science 
and  Technology  Objective  (STO)  initiated  by  the  Intelligence  and  Information 
Warfare  Directorate  (I2WD)  addresses  the  Army  need  to  locate  all  enemy 
emitters  on  the  battlefield  and  put  them  at  risk.  The  approach  is  to  utilize 
communications  platforms  as  non-traditional  Radio  Frequency  (RF)  sensors  to 
perform  other  functions  such  as  threat  detection,  spectrum  awareness,  and 
mapping  of  emitters  in  the  local  area.  Models  of  the  WECM  sensor  have  been 
built  and  used  in  the  Future  Combat  System  virtual  simulation  experiments  for 
the  last  2  years.  Experiment  feedback  has  indicated  that  WECM  provides 
useful  information  to  help  the  soldiers  accomplish  their  mission.  The  WECM 
STO  now  requires  a  tool  to  analyze  various  options  for  sensor  management. 
The  WECM  STO  manager  has  indicated  a  desire  to  use  the  NFSS-OMS  to 
satisfy  this  requirement.  The  endorsement  letters  signed  by  the  WECM  STO 
Manager  along  with  the  Mounted  Maneuver  Battlespace  Lab  (MMBL),  PM- 
Prophet,  and  PM-RUS  are  attached  at  the  end  of  this  proposal. 

•  Acoustic  Canopy  MASINT  System  (ACMS)  -  The  ACMS  system  is  being 
developed  under  another  SBIR  Phase  I  under  I2WD  with  Progeny  Systems. 
This  sensor  system  uses  miniature  acoustic  transducers  to  locate  and  track 
personnel  and  vehicles  in  densely  treed  areas.  The  sensors  can  be  deployed 
from  UAVs.  I2WD  has  requested  that  the  ACMS  be  integrated  with  the 
NFSS  for  Phase  n.  PSI  has  already  had  discussions  with  Progeny  Systems  on 
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how  the  NFSS-OMS  can  be  used  to  display  sensor  information  and  provide 
ACMS  sensor  coordination  and  control. 

•  Electronic  Support  for  the  Objective  Force  —  This  STO,  planned  to  start  in 
FY03,  will  address  current  sensor  information  distribution  and  communication 
requirements.  The  current  plan  is  to  expand  the  framework  started  under  the 
WECM  STO  into  a  broader  coverage  of  sensors.  Initial  discussions  with 

12 WD  indicate  that  the  plan  is  to  design  the  system  to  fit  directly  with  the 
NFSS,  and  using  the  NFSS-OMS  as  the  graphical  front  end  for  the  system. 

•  Future  Combat  System  (FCS)  -  The  MMBL  has  a  virtual  simulation 
environment  that  is  used  to  test  the  FCS  Unit  of  Action  of  the  Objective 
Force.  The  NFSS  will  provide  the  capability  to  manage  the  MASINT  sensor 
assets  used  by  the  Unit  of  Action.  This  capability  was  specifically  requested 
during  the  last  FCS  experiment.  It  will  also  provide  feedback  on  the  NFSS- 
OMS  design  and  interface.  The  NFSS-OMS  will  also  be  used  to  provide 
feedback  to  the  Ft.  Huachuca  analysts  at  the  FCS  experiment  who  require 
fused  sensor  data  to  assist  in  locating  OPFOR  Tactical  Operation  Centers 
(TOC).  The  MMBL  has  provided  an  endorsement  letter  along  with  the 
WECM  STO  Manger  that  is  attached  at  the  end  of  this  proposal. 
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